Real-time event-based notification system

ABSTRACT

Methods and systems are provided for generating alerts in association with a request for credit data or an update to credit data. For example, information identifying an individual may be received from a credit bureau when an individual applies for a product or service from a requesting entity. The requesting entity may be a product or service provider that requests credit data of potential purchasers of its products. An electronic notification may then be sent in association with an event object generated by a notification system that is broadcast for delivery to one or more other systems, where the event object may be broadcast substantially in real time, such as via an enterprise server bus, relative to the requesting entity&#39;s initial request.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. provisional application No.62/259,548, filed Nov. 24, 2015, the disclosure of which is herebyincorporated herein by reference in its entirety.

BACKGROUND

When an individual applies for a product or service with an entity, theentity often times requires credit information of the individual. Theentity requests credit information for the individual from a creditbureau. Then the entity factors in credit information when negotiatingthe terms of the product or service with the individual. For example, anentity may present a loan with lower interest rates for individuals withhigher credit scores than for individuals with lower credit scores.Credit information may also affect ancillary terms of an agreement. Forexample, the entity may require a different down payment for a realestate loan based on a credit score. When a credit bureau receives arequest for credit information regarding a given consumer from arequesting entity, the bureau typically retrieves the relevant data froma credit database maintained by the bureau, generates a credit score (ifrequested), returns the credit data and score to the requesting entity,and may record additional information in the consumer's credit file(such as recording that a credit inquiry was received).

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a functional block diagram showing a sample high-level flowof events related to a notification system, according to certainembodiments.

FIG. 1B is a functional block diagram showing another sample high-levelflow of events related to a notification system, according to certainembodiments.

FIG. 2A is a flowchart illustrating one embodiment of a method forsending a broadcast event to subscribers based on a request for creditdata.

FIG. 2B is a flowchart illustrating one embodiment of a method forsending a broadcast event to subscribers based on an action that affectscredit data.

FIG. 3A illustrates one embodiment of a system that implements aspectsof the present disclosure, such as broadcasting events to one or moresubscribers.

FIG. 3B is a flow diagram illustrating an example embodiment of anotification system that outputs custom payloads to multiplesubscribers.

FIG. 3C is a flow diagram illustrating the example notification systemexecuting a multi-phase processing of an event in order to generate acustom payload for a subscriber.

FIG. 3D is a flow diagram illustrating an example processing method thatmay be performed by the notification system to reduce processing cyclesrequired to identify matching listeners from a large set of multipleavailable listeners (e.g., hundreds, thousands, or millions of differentlisteners).

FIG. 3E is a flow diagram illustrating example event/payload data thatmay be transformed in various ways to provide a custom payload to asubscriber.

FIGS. 3F, 3G, and 3H are example payloads that may be provided to asubscriber.

FIG. 4A is an illustrative representation of a table associatingindividual consumer information with credit information and informationassociated with a request for credit data.

FIG. 4B is an illustrative representation of a table associatingfinancial institutions with vendors and/or service providers, along withcorresponding contact and other information.

FIG. 5 is an illustrative representation of block diagram illustratingthe ecosphere of notification system and associated modules.

These and other features will now be described with reference to thedrawings summarized above. The drawings and the associated descriptionsare provided to illustrate certain embodiments and not to limit thescope of the invention. Throughout the drawings, reference numbers maybe re-used to indicate correspondence between referenced elements.

DETAILED DESCRIPTION

Among other things, this disclosure describes systems and methods forproviding alerts in association with monitored events, where the alertsmay be electronically delivered to a number of event subscriberssubstantially in real time relative to the occurrence of an underlyingevent trigger.

In conventional negotiations and transactions, an entity that is sellingproducts or services may have more information (e.g. credit information)than a buyer when bargaining for the entity's products or services.Without understanding, at the point of negotiation, the condition of anindividual's credit data, the individual is placed at a disadvantage.The individual does not know whether an offer for sale or extension ofcredit is a reasonable one based on the individual's credit data.Furthermore, the individual may not know whether credit data can beeasily improved to order to simply return at a later time for a betterproduct or service. The individual may not know if the offer for theservice or product is reasonable based on other services and productsthat the individual is qualified for from other vendors.

Furthermore, credit data may be maintained by a credit bureau which mayinclude account data for millions of customers based on informationretrieved from a myriad of different sources. The credit bureaus receiveinformation that may result in changes to credit data (e.g. payments orinquiries change a credit file), but many of these payments take aboutthirty to sixty days to update. Generally, a credit bureau systemutilizes batch processing on a periodic basis to update the credit file.Thus, an individual may not have access to opportunities such as anextension of credit or better products or services until the updatetakes effect on the credit data. Product and service providers wouldalso have to wait before identifying the individual as having met acertain criteria for a product or service.

Disclosed herein are systems and methods for generating event objectsthat meet a certain criteria and then generating an alert including anevent message that may be electronically delivered to a number of eventsubscribers substantially in real time relative to the occurrence of anunderlying event trigger. In some embodiments, a “publish and subscribe”events-based architecture may be implemented to distribute the alert inreal time to target end point systems. Aspects of the present disclosureinclude a notification system that provides an alert to eventsubscribers to cause the event subscribers to send relevant informationto an individual (e.g. current credit data, credit score) in associationwith activity related to credit data, such as a request for credit datafrom the credit bureau, as well as providing notification to theindividual on other information (e.g. alternative products or services,suggestions and advice).

As used herein, a “notification module” generally describes anysoftware, firmware, and/or hardware that provides a backbone to publishand subscribe events. For example, a notification module may include anenterprise service bus (“ESB”), data streaming technology, or any othertechnology that can publish to subscribers. Certain examples hereinrefer to an enterprise bus or ESB for ease of description, but thoseembodiments may be implemented with any other notification modulediscussed herein and/or later developed. For example, the notificationmodule may leverage an Enterprise Service Bus (“ESB”) architecture whena trigger event meets certain broadcast criteria (e.g. an increase of acredit score by a certain value, a credit score meeting a threshold, ordebt below a certain number). The notification system may generate anevent object based on the broadcast criteria to post to an ESB, and thenotification module may send a broadcast event message based on theevent object to subscribers, allowing subscribers to obtain informationon the individual in real-time.

Subscribers may use the information in the event object to send alertsto individuals in real time. Equipping the individual with suchinformation empowers the individual with real time facts that will helphim or her in the negotiation process. For example, in some embodiments,information identifying an individual may be sent to a credit bureaufrom a requesting entity in response to a request for a car loan. Therequesting entity may be, in some embodiments, a vendor or serviceprovider for the car loan and the entity that receives information fromthe individual to send to the credit bureau asking for credit data. Inresponse to the credit bureau receiving the request for credit data fromthe requesting entity, the credit bureau may respond with credit data tothe requesting entity. The credit bureau may also determine informationderived from the inquiry (e.g. name of the requesting entity, purposefor the inquiry) and send the derived information to a notificationsystem.

The notification system may assess the information derived from theinquiry, in particular whether the information meets a certain broadcastevent criteria. This assessment may be the decisioning for generating abroadcast event object. For example, the notification system may assesswhether the request meets a certain criteria (e.g. a credit scoreincrease of 80 points or a total score greater than 700), which may beassociated with one or more subscribers. Based on such criteria, thenotification system may generate a broadcast event object. Thenotification system may generate a broadcast event object if theinformation received from the credit bureau indicates that a broadcastevent criteria has been met. In other embodiments, the notification maygenerate multiple broadcast event objects where each broadcast eventobject is created based on its own set of broadcast criteria, which mayeach have been established with respect to different subscribers.

In some embodiments, the notification system receives informationderived from the inquiry for credit data. The notification system canadditionally receive other information about the individual, such astransactional data, personal identification information (“PID”), medicalinformation, information associated with big data (e.g. search orbrowser history), and/or other information to determine and generate anevent. In some embodiments, the event can identify (or be associatedwith data that identifies) a category of subscribers to receiveinformation or updates associated with the individual. In someembodiments, the event can include information that can be posted to anenterprise service bus to be sent to subscribers to the enterpriseservice bus. The subscribers can then determine alerts that can begenerated that provide value to the individual. For example, theindividual may receive an alert that indicates the individual's latestcredit score and/or other relevant information (e.g. how the credit datahas changed recently, any mechanisms or actions that can be used orperformed to increase the credit score, and/or other information).

Furthermore, the subscriber may extend offers to the individualproviding the individual a baseline for the negotiation and thatprovides immediate alternative offers to compare. For example, thenotification system may receive an indication from the credit bureauthat the request for credit information came from a car dealership. Thenotification system may have a broadcast event criterion that identifiesrequests for individuals interested in a car loan. The notificationsystem may generate a broadcast event object for the criterion, and postthe broadcast event object to an ESB and/or other notification module.The ESB can then send a broadcast event message based on the broadcastevent object to subscribers that are subscribed to the broadcast eventcriterion. The subscriber may receive information that the individualrequested a car loan from a particular car dealership. The subscribermay determine loan details that the individual may be pre-qualified forto send to the individual based on the individual's credit data. Then,as the individual is negotiating with the car dealership, the individualwill be empowered with an alternative loan such that the individual cansimply walk away from the loan from the car dealership and go with theloan in the alert. The individual may also be equipped with sufficientinformation to understand that the individual can step away, takemitigating actions to improve the credit data, and reapply for theproduct/service for better terms.

Aspects of the present disclosure offer technical advancements thatprovide vendors and service/product providers with a new and effectiveway to market their products immediately at the point of sale.Traditionally, vendors and providers can send their marketing alerts atparticular times (e.g. daily, monthly), or embedded in certain websites(e.g. searching for a particular product on a search engine or socialmedia feed). However, aspects of the present disclosure provide anotification system that can generate a broadcast event object based oncertain criteria and utilize a notification module (e.g. an ESB) to senda broadcast event message to vendors and service/product providers insubstantially real-time from the event trigger in order to enablevendors and service/product providers to offer alternative offers forsale in real time as the individual is negotiating a competitor's offerfor sale.

Various embodiments of systems, methods, processes, and data structureswill now be described with reference to the drawings. Variations to thesystems, methods, processes, and data structures that represent otherembodiments will also be described.

Credit data may be maintained by a credit bureau or similar entity.Credit data maintained by a given credit bureau may include account datafor millions or even billions of customers, where each customeridentified in the data may have one or more accounts. The credit datamay be based on several sources of data which include existing tradedata, new trade data, inquiries, public record data (for example,bankruptcy filings), change of address data, and so forth. A common typeof credit data is “tradeline data” (or trade data). Tradeline data maybe an entry by a credit grantor to a consumer's credit history which ismaintained by a credit reporting agency. A tradeline describes theconsumer's account status and activity and can include names ofcompanies with which the applicant has accounts, dates the accounts wereopened, credit limits, types of accounts, account balances, paymenthistories, and/or other data.

In the United States, for example, multiple credit bureaus areconstantly receiving data from a large number of data sources,including, for example, banks, creditors and other account providers.The credit bureaus use the data, among other things, to provide creditreports, credit scores and other credit-related products or services toconsumers and businesses. The systems of a given credit bureau aretypically tailored to specific legal and business requirements based ona number of factors, as well as the needs of its customers, which mayhave evolved over a long period of time.

In the United States, three hundred million consumers make payments toover fifty thousand entities every month, totaling thirty-five billionpayments each year. The entities may include a variety of banks, utilitycompanies, property owners, and the like. Many of these payments takeabout thirty to sixty days to show up on the consumers' credit ledgersafter the payments are made. Generally, the reporting entities and atypical credit bureau system utilize batch processes on a periodic basisto update many aspects of a credit bureau's electronic records.

Disclosed herein are systems and methods for delivering key eventalerts, such as credit inquiries and credit dispute status updates, inreal time or near-real time from a system operated by a credit bureau toother systems either internal or external to the credit bureau. In someembodiments, a “publish and subscribe” events-based architecture may beimplemented to build a real time “pub/sub” protocol, wherebytransactions or business events from a producer system (e.g., a centralcredit bureau system, and/or various other systems) can be distributedto target end point systems (such as subscribers) simultaneously in realtime. In some embodiments, the notification system uses data streamingto distribute the events.

In some embodiments, an event may be sent via a notification module whena significant change of state occurs in the producer system in which oneor more target systems or end-point subscribers are interested. Thisevents-based architecture may complement Services Oriented Architectureprinciples, whereby each change of state in the producer system may beconsidered a unique event and wrapped as a “business service” to bedelivered to target end points or systems. Aspects of the presentdisclosure may provide a foundation for a loosely coupled enterprisearchitecture, thereby significantly reducing if not eliminating the needfor point-to-point integration between application systems and theassociated complexity.

Aspects of the present disclosure may leverage the capability of anotification module, such as an ESB, data streaming, or other publishand subscribe middleware, to implement an events-based architecture, andmay be used to deliver atomic events in a publish and subscribe model.The publisher may be a system of records that creates various atomicevents, and the subscriber may be a system that consumes the events. Thepublisher may deliver the events to various subscribers by posting theevent in an Enterprise Service Bus. In some embodiments, the ESB mayeliminate any point-to-point integration between the publisher andsubscriber, and act as a backbone channel for both delivery of events tomany subscribers and the clustering of different application systemswithin the enterprise. An ESB software suite, potentially combined withspecialized hardware in some embodiments, may provide a mechanismwherein the events manifested from the publishing system can becataloged, and each subscribing system can subscribe to certain atomicevents from the catalog based on event type and/or various data ormetadata associated with each event. In some embodiments, the publisherof events may not even know how many subscribers are there, as the ESBmay render these events to different subscribers through listeners whichare associated with each subscriber in the ESB framework. The ESB mayalso provide a flexibility whereby the role of producers and subscriberscan be reversed, so that each application system can be either producingevents or consuming events. In some embodiments, a single system may beboth a producer and subscriber with respect to different events. Forexample, a given system may automatically produce an event in responseto some other event that it consumes. The ESB backbone can also beleveraged, in some embodiments, to implement request-reply web servicesfor any application systems clustered in an ESB cluster.

In some embodiments, a publish and subscribe model as described hereinmay provide functionality whereby a publisher effectively posts an eventonce for consumption by a large number of listeners or subscribers.Individual listeners may be configured to react to certain eventsuniquely by event type and/or other information, then repost asubsequent response event to the ESB.

In general, it is desirable for the payload of an event posted to thebus to be relatively small (e.g., less than a few hundred bytes).Accordingly, in some embodiments, an application programming interface(“API”) and/or other functionality provided by an operator of a creditbureau may be configured to receive data from various sources andpackage the data into an event object in a manner that ensures a payloadsize below a pre-established threshold set based on size or efficiencybenchmarks established to meet the technical and/or business needs ofthe ESB and/or credit bureau. For example, the event may providenotification of a change in credit data, personal identificationinformation, information on the requesting entity, and/or other creditdata.

In some embodiments, an API may be provided that enables consumersand/or financial entities (e.g., banks, credit card providers, etc.) toreport credit data for inclusion in a credit bureau database in a realtime manner utilizing features of the ESB architecture. As volume needsincrease, systems disclosed herein may be scalable and self-adjusting,such as by automatically triggering multiple instances of an API toscale to volume or bandwidth needs. In some embodiments, many aspects ofthe system may be designed to have built-in redundancy and/or may bemodular in order to enable increased flexibility.

The data layout of an event may depend on the type of event. Forexample, a generic layout may be established and used for certainevents, while other events may be organized in a customized format basedon the event type, specific subscriber needs, the producer's needs,and/or other factors. As a specific example in one embodiment, thepayload of an event for reporting a credit inquiry may include fieldsindicating a consumer's basic information (e.g., name, birthday andsocial security number), credit data, address information, and the nameof the inquiring entity. In some embodiments, the payload of an eventmay be in a JSON format in order to minimize ties to any specificschema, although other configurations (e.g., XML) are contemplated andintended to be within the scope of this disclosure. In some embodimentswhere multiple payload formats can be posted to and processed by thesame ESB, only certain listeners/subscribers may be configured toprocess specific formats (e.g., a customized data layout may be used fora specific bank listener).

In some embodiments, the ESB may be configured to process both regulatedand non-regulated data. For example, certain types of credit data andpersonal information may be regulated by one or more government entitiesin a given region or country. The ESB may be configured such that anyevents posted to the bus are checked automatically to determine whetherthe data types involved trigger any rules that require certain consumerconsent or other special treatment. In the case that one or more consentrules are triggered, the producer system may be configured toautomatically check for a record of the appropriate consent in anelectronic data store, where the consent may have been previouslyobtained from a consumer via an API (such as the consumer agreeing tocertain consents when previously self-reporting credit data to thecredit bureau via an API, or in association with a firm offer ofcredit).

As mentioned above, a single system, in some embodiments, can act asboth publisher and subscriber. For example, a given listener (e.g., acontinuous scoring listener) can be configured to automatically performan action (e.g., generate a credit report) upon listening to a certaineven type, and then automatically post a resulting new event (e.g., acredit score) back to the ESB in real time. Events may be split intodifferent parallel queues based on filtering, rule sets and/or loadbalancing, then a regulator associated with a given queue may determineone or more specific listeners to receive each queued event.

According to certain embodiments, a notification system, which mayinclude an enterprise service bus, may broadcast an event to subscribersto cause the subscribers to provide an alert to an individual when anentity uses information of the individual to request credit data. Inother embodiments, the notification system may generate an event to senddirectly to a consumer computing device. In some such embodiments, theconsumer computing device may be a subscriber, and may launch anapplication upon receiving an event message in order to provideadditional related information to the consumer. For example, anotification system, as disclosed herein, may provide an alert to adevice associated with the individual when identification informationassociated with the individual is included in a request associated witha request for credit data, such as requesting a credit file.

In some embodiments, the credit bureau and/or the notification systemmay determine information underlying the request, such as the name ofthe requesting entity and/or the purpose for the request. Thenotification system may also determine third party vendors, financialinstitutions, or subscribers to which to broadcast the event. In someembodiments, the financial institution may be, for example, a bank orcredit card issuer that maintains credit accounts for individuals onbehalf of a separate entity, such as a vendor or service provider. Thenotification system may determine how the event will be broadcasted(e.g. categories of event receivers or particular receivers of thebroadcast event). The notification system may, in some embodiments,provide information associated with related offers (e.g. categories ofrelevant offers for the receivers of the broadcast event).

In some embodiments, the notification system as described herein mayinclude a subscription component. For example, the subscriptioncomponent may be offered via a monitoring service that enrolls thirdparties to the enterprise service bus to receive broadcast messages. Insome embodiments, a notification system may have a relationship with acredit bureau, or other entities (e.g. subscribers to the enterpriseservice bus, product or service providers, and/or financialinstitutions), such that certain requests that are received by thecredit bureau or other entities are sent to the notification systemprior to being processed by the credit bureau or the other entities.Furthermore, in some embodiments the notification system may be anintermediary that receives requests associated with a request for creditdata from requesting entities or financial institutions and transmitsthe requests to one or more credit bureaus or other entities after (orconcurrently with) extraction of information regarding an individualidentified in the request and initiation of alert transmission to theconsumer.

In some embodiments, alerts and/or events may be generated very quickly(e.g., in real-time or substantially in real-time) after a requestassociated with credit data or other event-triggering action occurs. Forexample, alerts may be transmitted to subscribers within seconds of thetriggering event occurring. Similarly, notifications from subscribersindicating feedback, relevant offers, suggestions, and the like may betransmitted to the individual also in real-time or substantially inreal-time. Although the disclosure discusses offers, feedback,information, and the like sent to the individual, the same notificationor alert can be sent to other entities (such as the requesting entity).In other embodiments, notifications or alerts to individuals may betransmitted in batches, where the batch processing may occur every Nseconds, minutes, hours, or other period.

In some embodiments, identity information that may be included in arequest for credit data may broadly include various types of dataassociated with an individual. Examples that may be considered identityinformation, in some embodiments, include name, address, telephonenumber, email address, social security number, etc. Although thedescription provided herein refers to individuals, consumers, orcustomers, the terms “user,” “individual,” “consumer,” and “customer”may, according to some embodiments, include groups of individuals, suchas, for example, married couples or domestic partners, organizations,groups, and business entities. Furthermore, request for credit data maybroadly include various types of data associated with the requestingentity, for example, requesting entity name, address, and the like. Therequest for credit data may also include information on the purpose ofthe inquiry, for example, a loan amount, a purpose for the loan, etc.

A request for credit data may generally refer to a request for moreinformation on the individual based at least in part on one or morepieces of identification information. For example, the request forinformation may be non-credit data and/or credit data. For the purposesof discussion, the request will be described as a request for creditdata directed to a credit bureau. In some embodiments, a request forcredit data may be a part of an account opening transaction or request.For example, when an entity initiates a process to open a new creditaccount or other account for an individual, the entity may first attemptto receive credit data of the individual. The entity may subsequentlyrequest credit data associated with the individual as a part of theaccount opening process. In other embodiments, the entity may open anaccount for the individual by submitting a credit data request. As willbe appreciated, examples described herein with reference to requests forcredit data may also be applicable to requests for other types ofrequests associated with the opening of an account, line of credit, orother transaction. Examples of account types that may be associated witha request to open a new account may include, for example, a mortgage, arevolving loan, a credit card, financial services, utilities, leasing,renting, television service, telephone service, and/or other types ofcredit or non-credit accounts.

FIG. 1A is a functional block diagram showing a sample high-level flowof events in a notification system, according to certain embodiments. Asshown in FIG. 1A, an individual applies for an account with a product orservice provider (requesting entity) 102. For purposes of example, theindividual applying for the account may be an individual named of JimSmith. The requesting entity 102 may be attempting to open a creditaccount, for example, in the name of Jim, such as a department storecredit card. As will be appreciated, the product or service provider(requesting entity) 102 could be any of a number of business typesinvolved in products or services, even for products or servicesancillary to credit data. For example, the requesting entity 102 may beinvolved in opening accounts for consumers, including credit accountsand/or non-credit accounts. While credit bureaus are often referred toin this disclosure to maintain credit data, it is appreciated that inother embodiments, some or all of the credit data may be maintained byother entities (such as the subscriber 105, financial institution 104,or third party vendor 103. In some embodiments, the requesting entitiesmay be the entities to receive the broadcast event message. In someembodiments, the entities receiving the broadcast event message may bethe requesting entity. Thus, a given system may both provide input tothe notification system that triggers an event object to be created, andmay receive event messages as a subscriber.

The credit bureau 120 may determine information regarding the requestfor credit data. For example, the credit bureau 120 may identify thename of the product or service provider (requesting entity) 102, thepurpose of the request for credit data, or the like. The credit bureau120 may retrieve credit data (e.g. a credit file) for the individualfrom a credit data store 121. In the illustrated example, the creditbureau 120 generates and provides the requested credit information tothe product or service provider 102. A request for credit data is alsosent to a notification system 150. As will be appreciated, requests forcredit data and/or other requests associated with an account opening mayadditionally or alternatively be received by entities other than acredit bureau (such as an authentication service in the event of anaccount opening transaction, where the authentication service may beoperated by the same operator or different operator than the creditbureau services).

In some embodiments, the notification system 150 may also receiveconsumer information from a consumer information data store 112. Forexample, the consumer information may include non-credit informationthat may be used by the notification system 150 when identifying whetheran incoming request or other occurrence satisfies criteria forbroadcasting the occurrence as a broadcast event. The consumerinformation may include information such as transaction data, browserdata, personal information, and/or any other information that may beused when determining whether to generate a broadcast event objectrelated to a request for data. Such information may be provided byfinancial institutions, credit bureaus, vendor or service providers, bigdata providers, the individual, and/or other entities that have relevantinformation on the individual. The consumer information data store 112may include multiple data stores, in some embodiments.

Next, in the embodiment illustrated in FIG. 1A, the notification system150 may identify that a broadcast event object related to the requestfor credit data should be generated as a result of the incomingnotification meeting previously established event criteria, as will bediscussed in more detail below. For example, the broadcast event objectmay include information regarding a credit file and/or other creditdata, changes in credit data, consumer information (such as personalinformation, and/or non-credit data such as browser history), requestingentity information, information related to the purpose for the requestfor credit information, and/or the like. The notification system 150 maycomprise a notification module, such as enterprise bus 155, datastreaming, or other technology that can publish to subscribers (hereinreferred to as an enterprise bus for convenience, but any discussions ofan enterprise bus are equally applicable to other notification module)as will be described in further detail below.

The notification system 150 may determine one or more broadcast eventtypes in response to information received by the credit bureau 120. Forexample, the notification system 150 may determine that one broadcastevent type is an increase in credit score over a specified threshold. Inanother example, the notification system 150 may determine a broadcastevent type based on the type of requesting entity 102 (e.g. a cardealership), or the purpose of the information received from the creditbureau 120 (e.g. a car loan). In some embodiments, the broadcastcriteria may include whether the information received by the creditbureau 120 falls under a particular event type. This event typeinformation may be incorporated into an event object generated by thenotification system 150.

In some embodiments, the notification system 150 may use the enterpriseservice bus 155 to send broadcast event messages to other entities. Forexample, the notification system 150 can send the broadcast eventmessage to subscribers 105 of the enterprise service bus. In someembodiments, the notification system 150 may send the broadcast eventmessage to third party vendors 103, financial institutions 104, and/orany other third party that may use the broadcast event message and/orrelated request information to determine an alert to send to theindividual.

In some embodiments, the notification module comprises data streamingconfigured to publish events to subscribers. Data streaming, as usedherein, generally refer to any technology that processes events in theorder they occur, and may include the transfer of data at a high speedsufficient to support sufficient bandwidth and for real-time humanperception of data. One example includes the KAFKA stream configured tostream messaging data in a publish and subscribe architecture. The KAFKAstream is a distributed streaming platform that allows the platform topublish and subscribe, to store streams of records, and to processstreams of records as they occur. Other examples of data streamingtechnology include FLINK, and SPARK. “The Forrester Wave™: Big DataStreaming Analytics, Q1 2016,” by Mike Gualtieri and Rowan Curran,published Mar. 30, 2016 by Forrester™, available athttp://www.sas.com/content/dam/SAS/en_us/doc/analystreport/forrester-big-data-streaming-analytics-108218.pdf,and “Top Streaming Technologies for Data Lakes and Real-Time Data” byGreg Wood, published Sep. 20, 2016 by Zaloni The Data Lake Company,available athttp://blog.zaloni.com/top-streaming-technologies-for-data-lakes-and-real-time-data,which are hereby incorporated by reference in their entirety, describeadditional details and options in using data streaming technology thatmay be used in certain embodiments of notification systems discussedherein. The notification module may include a form of middleware, datastreaming, other technology that may allow a system to publish/subscribearchitecture, to publish or sent to an entity to consume, or send tosubscribers of a certain event.

The entities (third party vendor 103, subscriber 105, and financialinstitution 104) that receive a broadcast event message may then,extract the information related to the request for credit data from themessage, and determine relevant offers to send to the individual. Then,one or more entities may send an offer, an alert, notification, and/ormessage to a consumer computing device 130. The alert may include anotification of information (e.g. current credit score), suggestions forthe consumer (e.g. mitigation factors to increase credit score),competing offers (e.g. other offers for a car loan), or any otherinformation that may be helpful for the individual (e.g. helpful for thepurpose of the inquiry).

The event message receiving entities (third party vendor 103, subscriber105, financial institution 104) may, in some embodiments, de-dupe,parse, and/or re-phrase the broadcast event messages received from thenotification system 150. For example, multiple alerts may be generatedby the entities (third party vendor 103, subscriber 105, and/orfinancial institution 104) for the same consumer activity, such as whenmultiple entities may generate and transmit alerts to the consumercomputing device 130. The consumer computing device 130 and or othersystem may parse and/or re-phrase the alert to make it user friendly.For example, the consumer computing device 130 may correlate informationincluded in the alert, such as alert type, with a particular alertmessage and/or integrate the messages together in a single applicationor message. Additionally, different alert messages or formats may beaccessed depending on the delivery medium, such as e-mail, softwareapplication, SMS, voice, etc.

The notification system 150 and/or an entity that receives an eventmessage (such as third party vendor 103, subscriber 105, or financialinstitution 104) may determine contact information and/or contactpreferences for the individual based on, for example, information thatthe individual provided when enrolling in a monitoring service oralert/notification service. The one or more alerts may be provided invarious manners, and may depend in part on the device type. For example,alerts may be delivered, in some embodiments, via one or more of e-mail,text message, phone call, an online portal that is accessible to alertmembers (e.g., a credit monitoring or identity protection website),printed digests, mobile applications, etc.

In the embodiment of FIG. 1A, the individual may provide an indicationback to the relevant entity (such as third party vendor 103, subscriber105, or financial institute 104) to receive more information on theoffer, such as details on the counter offer or view mitigating steps toimprove credit score. The respective entity (such as third party vendor103, subscriber 105, or financial institute 104) may implement one ormore responsive actions in order to provide the individual with moreinformation, or more detail on the contents of the offer. In someembodiments, the individual may have preconfigured notification/alertpreferences. For example, the individual may allow for certainnotifications (such as alternative counter-offers), but not authorizemessages to be sent suggesting mitigating steps to improve theindividual's credit score.

The alerts to consumers may include detailed information regarding therequesting entity. For example, rather than simply indicating the nameof a chain store from which the request for credit data was received, insome embodiments the alerts may include the particular informationregarding the individual that was provided to the requesting entity.Having more detailed information on the information provided to therequesting entity allows the consumer to better determine itsnegotiation stance.

FIG. 1B is a functional block diagram showing another sample high-levelflow of events in a notification system, according to certainembodiments. As shown in FIG. 1B, an individual can perform an actionwith a product or service provider (requesting entity) 102 that affectscredit data. For example, the individual may have a debt with theproduct or service provider 102. However, the individual may pay off thebalance of the debt, which would thereby affect the individual's creditscore. Accordingly, as illustrated, the product or service provider 102may send updated information on the action (e.g. paying off the debt) asperformed to the product or service provider 102 by the individual.Alternatively, the credit bureau 120 may request such information uponthe change, at different time intervals, upon a request for suchinformation (e.g. request for a credit file), and the like.

The credit bureau 120 may update the credit data store based on theinformation related to the action that affects the credit data (e.g.paying off the debt). For example, the credit bureau 120 may updatestatistics on the credit file, such as total debt, or the like. Thecredit bureau 120 may also generate updates on the credit file, such asan updated credit score. The updated credit data and/or the action thataffects the credit data can also be sent to the notification system 150.As will be appreciated, updates to the credit data may additionally oralternatively be received by entities other than a credit bureau.

In some embodiments, the notification system 150 may also receiveconsumer information from a data store 112, similar to FIG. 1A. Next, inthe embodiment illustrated in FIG. 1B, the notification system 150 maygenerate a broadcast event object related to the credit data and/oraction that affected the credit data. For example, the broadcast eventobject may include information associated with a credit file and/orother credit data, changes in credit data, consumer information (such aspersonal information, non-credit data such as browser history),requesting entity information, information related to the purpose forthe request for credit information, and/or the like.

In some embodiments, the notification system 150 may use the enterpriseservice bus 155 to send broadcast event messages to other entities, asin FIG. 1A. The other entities (such as third party vendor 103,subscriber 105, and/or financial institution 104) may then each receivea broadcast event message, extract the information related to theupdated credit data and/or actions that affected the credit data,determine relevant offers to send to the individual, and send an offerto a consumer computing device 130, as in FIG. 1A.

Although the embodiments of FIGS. 1A and 1B describe the notificationsystem 150 including the enterprise service bus 155, and entities (e.g.subscriber 105, financial institution 104, third party vendor 103)external to the notification system 150, it is appreciated that part orall of the enterprise service bus 155 (and other modules described inthe notification system 150 in FIG. 3A) may be placed external to thenotification system 150, and part or all of the entities (e.g.subscriber 105, financial institution 104, third party vendor 103) maybe local to the notification system 150.

FIG. 2A is a flowchart illustrating one embodiment of a method forsending a broadcast event message to subscribers based on a request forcredit data, as described in FIG. 1A. The illustrative method may beimplemented by a notification system, such as the notification system150. In some embodiments, the notification system 150 may include anenterprise service bus 155 that implements some of the steps of themethod illustrated in FIG. 2A. The illustrative method begins at block202, where the notification system 150 receives an indication related toa requesting entity's request for credit data of an individual or otherentity. As discussed above, an individual may apply for a service orproduct from a service or product provider 102. The request may beassociated, for example, with a transaction to open an account on behalfof the individual. As used in the illustrated example, the underlyingvendor or service provider 102 that submitted the initial request to thecredit bureau 120 may be referred to as the requesting entity 102. Inother embodiments, the notification system 150 may receive theindication related to the request for credit data from an entity otherthan the credit bureau 120, such as a subscriber 105, a financialinstitution 104, a third party vendor 103, an authentication service, orother entity.

Once the notification system 150 receives the indication related to arequesting entity's request for credit data, the method proceeds toblock 204, where the notification system 150 accesses informationassociated with the identified consumer. The information can includepersonal identification information of the individual, transaction data,sociodemographic information, preferences, browser history, and/or anyother information relevant to the consumer. For example, thenotification system 150 may retrieve contact information from one ormore data stores based on a determined match between the consumeridentification information included in the request for credit data andcontact information associated with a number of different consumers. Thecontact information retrieved may include, for example, one or more ofan e-mail address, phone number, address, IP address, a user accountname associated with enrollment in a monitoring service, etc.

At block 206, the notification system 150 may, in some embodiments,determine if the request for credit data meets event broadcast criteriabased on the indication related to a requesting entity's request forcredit data. The notification system 150 can also use a variety of otherinformation in its decisioning whether to generate and/or how togenerate the broadcast event object. The notification system 150 can useinformation directed to a change in the credit file. For example, thenotification system may generate a broadcast event object if the creditscore has increased by 80 points, or if the total credit score is above700. The notification system 150 may also apply criteria directed to therequesting entity. For example, the notification system 150 may generatea broadcast event object if the requesting entity is associated withluxury brands (e.g. generate a broadcast event object if the requestingentity is associated with a luxury brand car dealership).

In some embodiments, the notification system 150 may generate abroadcast event object based on information on the requesting entity.The notification system 150 may generate an event broadcast criteriawhen the request for credit data is associated with a particularfinancial institution. For example, a subscriber that is a financialinstitution may subscribe for broadcast event messages that areassociated with itself or its competitors. A financial institution maydesire to receive messages in real time for requests associated withitself to identify better offers than the ones allowed by the requestingentity. The financial institution may have special promotions or have along standing relationship with the individual that the financialinstitution would like to promote and foster. In some embodiments, therequest for credit data may only provide the name of the requestingentity and not a financial entity associated with the requesting entity.The notification system 150 may retrieve data from one or more datastores that associates each of a number of different financial entitieswith one or more requesting entities with which the given financialentity is associated. Such association data is described with moredetail below with reference to FIG. 4B. In this manner, the notificationsystem 150 may set criteria to create a broadcast event object based onan association with a financial institution even if the request forcredit data does not contain the financial institution. For example, ifthe data store links a real estate company to a particular financialinstitution, then the notification system can identify the financialinstitution from the identity of the real estate company that may be therequesting entity requesting credit data. In some embodiments, thenotification system 150 and/or the subscriber 105 may provide theconsumer directly with an alert about the specific underlying requestingentity in order for the consumer to better determine if the offer forthe service or product is a fair one.

In some embodiments, the notification system 150 may generate abroadcast event object based on criteria related to information on theindividual. The notification system 150 may generate a broadcast eventobject for a particular individual, or characteristic associated withthe individual. For example, the notification system 150 may generate abroadcast event object for individuals based on gender,geolocation/residence, socio-economic attributes, race, age, level ofeducation, income and employment, psychiatric or medical data, apersonality trait, an interest, values, attitudes, lifestyles, opinions,preferences, likes or dislikes, predilections, purchase history, browserhistory, financial history and data, credit history and data, personalhistory and data, other activity data, and the like. The notificationsystem 150 may receive information from the credit bureau 120 that mayidentify the individual, and may access other information on theindividual from the consumer information data store 112.

In some embodiments, the notification system 150 may generate abroadcast event object based on criteria related to the request itself.For example, the notification system 150 may generate an object if thereare a number of requests by a particular requesting entity or for aparticular individual. Subscribers may subscribe to receive broadcastevent messages when multiple occurrences of a request for credit file isplaced for a particular individual. The notification system 150 may alsoassess the purpose of the inquiry to determine whether to generate abroadcast event object. For example, the notification system 150 maygenerate a broadcast event object for requests to open a line of credit,or for real estate loans for a particular amount in a specified area.

At block 208, the notification system 150 generates a broadcast eventobject associated with the request for credit information and optionallyother non-credit information (e.g. information regarding the requestingentity, information regarding the consumer, etc.), and, at block 210,posts a corresponding broadcast event message to an intermediary messagebroker. The broadcast event object may include the indication related tothe requesting entity's request, information on the requesting entity,information on the individual, information on the request itself (suchas the purpose of the request), the criteria for the broadcast eventobject, the intermediary message broker, and/or other information thatmay be used by the intermediary message broker, the enterprise servicebus 155, the individual, or the subscriber 105. The enterprise servicebus 155 identifies subscribers 105 registered to receive subscriptionsfrom the intermediary message broker at block 212. In some embodiments,each subscriber may be subscribed to one or more broadcast criteria. Forexample, a subscriber may be subscribed to receive broadcast eventmessages where (1) credit score is greater than 700, as well asreceiving broadcast event messages from (2) individuals residing inCalifornia.

At block 214, the notification system 150 transmits the broadcast eventmessage to subscribers 105 to cause the subscribers 105 to determinerelevant offers for the entity (e.g. the individual) based on theindication related to the requesting entity's request for credit data atblock 204. The broadcast event message may include at least a portion ofthe broadcast event object, routing information, information on thesubscriber, and the like. Then, the subscribers can transmit anotification or alert to the consumer using one or more delivery mediumsaccording to the contact information retrieved. For example, the alertmay be delivered via e-mail, within a software application, an onlineportal or website, SMS text message, voice call, etc. In someembodiments, the delivery method may be selected based on preferencespreviously provided by the consumer. In some embodiments, the blocks ofFIG. 2A may all be performed substantially in real time (such as withinseconds or milliseconds, in one embodiment) with respect to theindication being received at block 202.

FIG. 2B is a flowchart illustrating one embodiment of a method forsending a broadcast event message to subscribers based on an actionaffecting credit data (such as paying off debt), as described in FIG.1B. The illustrative method may be implemented by a notification system,such as the notification system 150. In some embodiments, thenotification system 150 may include an enterprise service bus 155 thatimplements some of the steps of the method illustrated in FIG. 2A. Theillustrative method begins at block 232, where the notification system150 receives information on an action that affects credit data. Asdiscussed above, an individual may pay off a debt owed to a service orproduct provider 102. As used in the illustrated example, the underlyingvendor or service provider 102 that submitted the change to the creditbureau 120 will be referred to as the reporting entity. In otherembodiments, the notification system 150 may receive the indicationrelated to a change, update, or action that affects credit data from anentity other than the credit bureau 120, such as a subscriber 105, afinancial institution 104, a third party vendor 103, or other entity.

Once the notification system 150 receives the indication related to arequesting entity's request for credit data, the method proceeds toblock 234, similar to block 214, where the notification system 150accesses information associated with the identified consumer. Theinformation can include personal identification information of theindividual, transaction data, sociodemographic information, preferences,browser history, and/or any other information relevant to the consumer.For example, the notification system 150 may retrieve contactinformation from one or more data stores based on a determined matchbetween the consumer identification information included in the requestfor credit data and contact information associated with a number ofdifferent consumers. The contact information retrieved may include, forexample, one or more of an e-mail address, phone number, address, IPaddress, a user account name associated with enrollment in a monitoringservice, etc.

At block 236, the notification system 150 may, in some embodiments,determine if the information regarding the action that affects creditdata meets an event broadcast criteria. The notification system maygenerate a broadcast event object based on criteria relating to theindividual, the requesting entity, the action affecting credit data, andthe like. For example, the broadcast event criteria may include athreshold or a particular change to the credit data (e.g. an increase of50 points to the credit score) that one or more subscribers havepreviously indicated an interest in being notified about.

At block 238, the notification system 150 generates a broadcast eventobject associated with the information on the action that affects thecredit data and other non-credit information (e.g. information on therequesting entity, information on the consumer), and, at block 240,posts the broadcast event object to an intermediary message broker. Theenterprise service bus 155 identifies subscribers registered to receivesubscriptions from the intermediary message broker at block 242, and atblock 244, the notification system 150 transmits the broadcast eventobject to subscribers to cause the subscribers to determine relevantoffers for the entity based on the information on the action thataffects credit data. Then, the subscribers can transmit a notificationor alert to the consumer using one or more delivery mediums according tothe contact information retrieved. In some embodiments, the blocks ofFIG. 2B may all be performed substantially in real time (such as withinseconds or milliseconds, in one embodiment) with respect to theinformation being received at block 232.

FIG. 3A illustrates a notification system 150 in communication withvarious systems, according to one embodiment. As illustrated, thevarious systems are in communication via network 160, which may be oneor more of a LAN, WAN, and/or the Internet, for example. As illustrated,the notification system 150 is in communication with a consumercomputing device 130. The notification system 150 may receive requestfor credit data from a credit bureau 120, which may provide the basisfor the notification system 150 to generate and deliver an alert to oneor more entities (such as third party vendor 103, financial institution104, and/or subscriber 105). Alternatively or additionally, thenotification system 150 may receive notification of a request for creditdata for a given consumer from an entity (e.g. third party vendor 103,financial institution 104, or subscriber 105), which may be a basis foran alert to be delivered to the consumer, in some embodiments. As willbe appreciated, the alert delivery device may be in communication withcredit bureaus, a number of other alert providers, vendors, serviceproviders, and consumer devices not illustrated in FIG. 3A.

In the illustrated embodiment, a notification system 150, which includesan enterprise service bus 155, a services registry 310, a servicesorchestration 320, a generic score monitoring listener 330, and ascore-able events listener 340, is in communication with a network 160and various systems are also in communication with the network 160. Thenotification system 150 may be used to implement systems and methodsdescribed herein. For example, the notification system 150 may beassociated with an event generator that causes an event to bebroadcasted to another entity (e.g. third party vendor 103, financialinstitution 104, and/or subscriber 105) to deliver a notification oralerts to a user. The alert and/or notification can additionally oralternatively be performed by the notification system 150. In otherembodiments, a credit bureau, third party vendor 103, financialinstitution 104, subscriber 105, and/or other third-party system mayinclude a computing system that includes components of notificationsystem 150.

The notification system 150 may include, for example, a personalcomputer that is IBM, Macintosh, or Linux/Unix compatible or a server orworkstation. In one embodiment, the notification system 150 comprises aserver, a laptop computer, a cell phone, a personal digital assistant, akiosk, or an audio player, for example. In one embodiment, the exemplarynotification system 150 includes one or more central processing unit(“CPU”) (not shown), which may each include a conventional orproprietary microprocessor. The computing system 700 further includesone or more memory (not shown), such as random access memory (“RAM”) fortemporary storage of information, one or more read only memory (“ROM”)for permanent storage of information, and one or more mass storagedevice (not shown), such as a hard drive, diskette, solid state drive,or optical media storage device. Typically, the modules of thenotification system 150 are connected to the computer using a standardbased bus system (not shown). In different embodiments, the standardbased bus system could be implemented in Peripheral ComponentInterconnect (“PCI”), Microchannel, Small Computer System Interface(“SCSI”), Industrial Standard Architecture (“ISA”) and Extended ISA(“EISA”) architectures, for example. In addition, the functionalityprovided for in the components and modules of notification system 150may be combined into fewer components and modules or further separatedinto additional components and modules.

The notification system 150 is generally controlled and coordinated byoperating system software, such as Windows XP, Windows Vista, Windows 7,Windows Server, Unix, Linux, SunOS, Solaris, or other compatibleoperating systems. In Macintosh systems, the operating system may be anyavailable operating system, such as MAC OS X. In other embodiments, thenotification system 150 may be controlled by a proprietary operatingsystem. Conventional operating systems control and schedule computerprocesses for execution, perform memory management, provide file system,networking, I/O services, and provide a user interface, such as agraphical user interface (“GUI”), among other things.

The exemplary notification system 150 may include one or more commonlyavailable input/output (I/O) devices and interfaces (not shown), such asa keyboard, mouse, touchpad, and printer. In one embodiment, the I/Odevices and interfaces (not shown) include one or more display devices,such as a monitor, that allows the visual presentation of data to auser. More particularly, a display device provides for the presentationof GUIs, application software data, and multimedia presentations, forexample.

In the embodiment of FIG. 3A, the I/O devices and interfaces provide acommunication interface to various external devices. In the illustratedembodiment, the notification system 150 is electronically coupled to anetwork 160, which comprises one or more of a LAN, WAN, and/or theInternet, for example, via a wired, wireless, or combination of wiredand wireless, communication link. The network 160 communicates withvarious computing devices and/or other electronic devices via wired orwireless communication links.

According to FIG. 3A, information is provided to the notification system150 over the network 160 from one or more data sources including, forexample, the credit bureau 120, or other entities (e.g. third partyvendor 103, financial institution 104, and/or subscriber 105). Theinformation supplied by the various data sources may include a requestfor credit information such as credit data, personal information,application information, and/or other like data, notification of arequest for credit information, or information on the requesting entityor the purpose for the request, for example. In addition to the devicesthat are illustrated in FIG. 3A, the network 160 may communicate withother data sources or other computing devices, such as a requestingentity 102. In addition, the data sources may include one or moreinternal and/or external data sources. In some embodiments, one or moreof the databases or data sources may be implemented using a relationaldatabase, such as Sybase, Oracle, CodeBase and Microsoft® SQL Server aswell as other types of databases such as, for example, a flat filedatabase, an entity-relationship database, and object-oriented database,and/or a record-based database.

A consumer computing device 130 may be connected to the network 160 andused by a user to receive and respond to alerts provided by thenotification system 150. The consumer computing device 130 may be adesktop computer, a mobile computer, or any other mobile device such asa mobile phone or other similar handheld computing devices. In someembodiments, a consumer can be a subscriber. For example, a consumer maysubscribe to receive broadcast event messages from the notificationsystem 150 on a consumer computing device 130.

In the embodiment of FIG. 3A, the notification system 150 also includesan enterprise service bus 155, a services registry 310, a servicesorchestration 320, a generic score monitoring listener 330, and ascorable events listener 340 that may be stored in the mass storagedevice as executable software code that is executed by the CPU. Thiscomponents or modules may include, by way of example, softwarecomponents, object-oriented software components, class components andtask components, processes, functions, attributes, procedures,subroutines, segments of program code, drivers, firmware, microcode,circuitry, data, databases, data structures, tables, arrays, andvariables. In the embodiment shown in FIG. 3A, the notification system150 is configured to execute the enterprise service bus 155, a servicesregistry 310, a services orchestration 320, a generic score monitoringlistener 330, and a scorable events listener 340 in order to receiveindication of a request for credit information or other underlyingaction or occurrence, generate event objects and messages, transmitbroadcast event messages to other entities (e.g. third party vendor 103,financial institution 104, and/or subscriber 105), receive feedback fromconsumers regarding provided alerts, and/or other functionalitydescribed elsewhere in this specification.

The notification system 150 may include an enterprise service bus 155that includes several process clusters (process cluster 1 302, processcluster 2 304, process cluster 3 306) to process services related to thenotification system 150. The notification system 150 may also include aservices registry 310 that is used to publish or post events to theintermediary message broker. In some embodiments, the service registrystores a catalog or index of events that the subscriber can access toselect event subscriptions. The catalog of events may include a groupingof event types or may include an a la carte selection of differentlistings of events. For example, a new inquiry for a credit file may bean event type, and may publish to any subscribers who are interested ina new inquiry. Account level events may be another example of an eventtype, where account level events may include changes to accountinformation (e.g. balance updates), adding an authorized user,opening/closing an account, and the like. Depending on the embodiment,the subscriber can subscribe to event types on various levels ofgranularity, such as subscribing generally to “account level events” aswell as subscribing to individual account level events, such as one ormore of those noted above. In some embodiments, each subscriber hasassociated access rights that identify types of events, sets ofconsumers, and/or other criteria required for that subscriber to enrollfor notifications of particular events. For example, a financialinstitution may be limited to subscribing to events for that financialinstitutions customers. In some embodiments, each subscriber must have a“permissible purpose” under applicable Fair Credit Reporting Act (FCRA)regulations to access credit data of consumers associated withsubscribed events.

The intermediary message broker (also referred to as the servicesorchestration 320, or bus) may also be included in the notificationsystem 150, used to broker messages, and perform mediation andtransformation of the events. The services orchestration 320 may useEBS, other middle layer technology, data streaming, or other technologythat is able to recognize events and publish events to subscribers tothe event.

For example, the mediation and transformation of the events may includechanging the payload to the format that the subscriber 105 has enrolledin. In some embodiments, the mediation and transformation may alsoinclude changing payload formats for consumer computing devices that thesubscribers 105 will send alerts and notifications to. The mediation andtransformation can change the payload to a text file to send as a textmessage or format the message to fit in an application of a mobiledevice. The notification system 150 may also include generic scoremonitoring listener 330 (also referred to as a custom score listener)that may be created for subscribers that request to listen to a scoreevent (e.g. listen to score changes and have the ability to select scoreranges to tune into). The notification system 150 may connect to one ormore subscriber systems for decisioning services based on the creditdata. The notification system 150 may also include a score-able eventslistener 340 that may be used to listen to real time events such as hardinquiries, credit card payments, etc. The score-able events may flowinto a scoring process that invokes a credit score calculator, creates apayload containing consumer identification and an updated credit score,and posts the score event back onto the bus.

While an enterprise service bus is often used as an example herein,other forms of middleware may be used in addition to or instead of anESB, in some embodiments, or data streaming technology may be utilized.Middleware may include any hardware and/or software suitably configuredto facilitate communications and/or process transactions betweendisparate computing systems. Middleware may be implemented throughcommercially available hardware and/or software, through custom hardwareand/or software components, or through a combination thereof. Middlewaremay reside in a variety of configurations (e.g. as a part of thenotification system 150), may exist as a standalone system, or may be asoftware component residing on the Internet server. Middleware may beconfigured to process transactions between the various components of anotification system 150 and any number of internal or external systemsfor any of the purposes disclosed herein. In various embodiments, wheremore than one notification system 150 components are dispersed across anetwork, middleware may be used to carry messages between components.These messages could be organized in any logical manner. WebSphere MQ™(formerly MQSeries) by IBM, Inc. (Armonk, N.Y.) is an example of acommercially available middleware product. An Enterprise Service Bus(“ESB”) application is another example of middleware.

The credit bureau system 120 may include a credit data store 121 thatcontains credit data for individuals, businesses, and/or entities. Thecredit bureau 120 may include a batch processing system 350 thatprocesses the individual modules in batches, where the batches mayinclude: inquiry updates 352, public record updates 354, single updates360, trade updates 356, changes of addresses 358 or other personalinformation, consumer updates 362, a PIN merge 364, a PIN split 366,and/or other processes 368. In other embodiments, the credit bureauprocesses these modules in substantial real time upon receipt of achange, request, or other action or information that would initiate anaction performed with respect to any one of these modules.

A consumer may include any individual, user, business, entity,government organization, software and/or hardware that interacts with asystem to receive offers for products or services. A consumer computingdevice 130 may include any hardware and/or software suitably configuredto facilitate input, receipt and/or review of information relating toalerts, notifications, and the other means of communication that mayinclude information on the consumer, such as credit data and/or offersfor products and services.

A consumer computing device 130 may include any device (e.g., personalcomputer) which communicates (in any manner discussed herein) via anetwork. The consumer computing device 130 may take the form of acomputer or set of computers, although other types of computing units orsystems may be used, including laptops, notebooks, hand held computers,personal digital assistants, set-top boxes, workstations,computer-servers, main frame computers, mini-computers, PC servers,pervasive computers, network sets of computers, and/or the like.

As used herein, the term “network” (or similar terms) shall include anyelectronic communications means which incorporates both hardware andsoftware components of such. Communication among the parties may beaccomplished through any suitable communication channels, such as, forexample, a telephone network, an extranet, an intranet, Internet, pointof interaction device (point of sale device, personal digital assistant,cellular phone, kiosk, etc.), online communications, satellitecommunications, off-line communications, wireless communications,transponder communications, local area network (LAN), wide area network(WAN), virtual private network (“VPN”), networked or linked devices,keyboard, mouse and/or any suitable communication or data inputmodality. Moreover, the network 160 may also be implemented using IPX,Appletalk, IP-6, NetBIOS, OSI, any tunneling protocol (e.g. IPsec), orany number of existing or future protocols.

FIG. 3B is a flow diagram illustrating an example embodiment of anotification system 150 that outputs custom payloads 302B to multiplesubscribers 105A, 105B, 105N (herein referred to as subscribers 105). Asdiscussed above, in some embodiments the services registry 310 allowssubscribers 105 to indicate which of multiple credit events 301 theparticular subscriber 105 would like to receive. Thus, for a particularcredit event type (or other credit event criteria that may be identifiedby a potential subscriber 105), multiple subscribers 105 may requestreceipt of matching events 301 (or custom payloads that are generatedbased on the matching events). In FIG. 3B, the notification system 150receives an event 301 that executes one or more process clusters 302,304,306 to generate a generic payload 302A. Then, the generic payload302A is provided to the notification module 154 (or some other componentsuch as data stream) as an event, such that the notification module 154may trigger one or more additional process clusters 302, 304, 306 basedon receipt of the generic payload event. Additionally, the genericpayload 302A is processed by one or more listeners 330A, 330B, 330N(herein referred to as listener 330A) to determine if any custompayloads 302B should be generated. As discussed elsewhere herein, eachof the listeners 330 include criteria, rules, requirements, etc. foridentifying particular events, which will then be processed to generatecorresponding custom payloads 302.

In the example of FIG. 3B, the listener 330A determines that the genericpayload 302A matches criteria for generating a custom payload 302B bythe listener 330A. One or more additional listeners may also generatecustom payloads based on matching the listener criteria to the genericpayload 302A. The listener 330A then generates the custom payload 302Band transmits to any subscribers 105 that have subscribed to receivethat custom payload 302B. In the example of FIG. 3B, the custom payload302B is transmitted to each of multiple subscribers, including 105A,105B, and 105N (which signifies that any amount of subscribers mayreceive that same custom payload 302B). As an example application ofFIG. 3B, the event 301 may comprise an indication of a late payment thatis received from a bank on a consumer's credit card account. The genericpayload 302A may be triggered based on a rule that indicates a newcredit score should be calculated when any of a certain group of changesare identified, including a late payment. Thus, the listener 330 A maythen generate the particular consumer's credit score as the custompayload 302B and transmit the newly calculated credit score to multiplesubscribers. Furthermore, each subscriber 105A, 105B, and 105N mayreceive the same custom payload 302B. In other embodiments, eachsubscriber 105A, 105B, and 105N may request a payload that is customizedto the subscriber 105A, 105B, and 105N (e.g. different formats, varyinglevels of information). The payload can also be published as anapplication program interface (API) or implemented as an HTTP directpush.

FIG. 3C is a flow diagram illustrating the example notification system150 executing a multi-phase processing of an event in order to generatea custom payload for a subscriber. In this example, the event 301 isinitially transformed into a generic payload 302A which is detected bythe listener 330A. The listener 330A then transforms the generic payload302A into a custom payload 302B. In some embodiments, the custom payload302B may be transmitted to one or more subscribers (not shown in thisfigure). In this example, the custom payload 302B is provided back tothe notification module 154 (or some other component of the notificationsystem 150 such as a data stream component), such as in the form of anevent. Listener 330B then identifies custom payload 302B as matchingthat listeners processing criteria. Thus, Listener 330B generates custompayload 302C which, again, is provided back to the notification module154. The custom payload 302C is identified by listener 330C as matchingthat listener's criteria, which generates custom payload 302D fortransmission to a subscriber 105C. As one example of the variouspayloads, the generic payload 302A may be a credit inquiry, payment on acredit account, balance change, late fee, etc. The custom payload 302Bmay be a credit score, such as the Experian Plus credit score, thecustom payload 302C may be a customer specific risk score (e.g., alender-specific risk score), and payload 302D may includeprequalification results that are based at least on the lender-specificrisk score. Advantageously, each of the custom payloads may beidentified by multiple listeners and processed into multiple differentcustom payloads. Thus, a single event 301 may advantageously triggergeneration of one or more custom payloads and transmission of one ormore different custom payloads to a plurality of subscribers, all insubstantially real-time in response to the notification system 150receiving the event 301. For example, the prequalification offers may beprovided to the subscriber 105C, such as an automobile lender, while theconsumer is at the point of sale, e.g. the automobile dealership, inresponse to the consumer paying off a credit card balance to increasethe consumer's credit score and chances of the consumer qualifying foran automobile loan. In this example, the listeners 330A, 330B, 330C areinternal subscribers to the notification system 150 and the subscriber105C is external to the notification system 150. However, it isappreciated that listeners 330A, 330B, 330C and the subscribers 105 maybe external, internal, or a combination of internal and external to thenotification system 150.

FIG. 3D is a flow diagram illustrating an example processing method thatmay be performed by the notification system 150 to reduce processingcycles required to identify matching listeners from a large set ofmultiple available listeners (e.g., hundreds, thousands, or millions ofdifferent listeners). As discussed above, the listeners may includegeneric listeners 330G which are triggered when generic payloads areplaced on the bus, and custom listeners 330C, which are triggered whencustom payloads are placed on the bus. In this embodiment, thenotification module 154, or some other component of the notificationsystem 150 (such as data stream), determines whether an event 301comprises a generic payload or a custom payload (e.g., whether the eventis received from a financial institution or from an internal listener)and provides the payload to only a set of corresponding listeners. Forexample, any new events or payloads received by the notification module154 would be analyzed by the generic listeners 330G. Similarly, anycustom payloads received by the notification module 154 are processed bythe custom listeners 330C. In this way, processing of incoming events isoptimized by reducing processing power required and increasing speed atwhich events may be processed.

FIG. 3E is a flow diagram illustrating example event/payload data thatmay be transformed in various ways to provide a payload to a subscriber.In this example, the event comprises information regarding a balancechange on an account owned by John Doe in the amount of −$400, andresulting in an account balance of zero dollars. In this example, thenotification module 154 makes the payload available to the listeners, orto only a set of generic listeners in some embodiments. In the exampleof FIG. 3E, a listener 330A is illustrated as triggering generation of apayload in response to the event, but as discussed above, multiplelisteners may be triggered in response to the same payload. In thisexample, the custom payload A comprises a credit score of 725 for JohnDoe, who is identified only by an alphanumeric identifier in thisexample payload. As shown, that payload A is made available to thelisteners by the notification module 154 and, in this example, triggerslistener 330B, which generates a bank-specific risk score for John Doeof BBB. For example, the bank-specific risk score may be calculatedbased on an algorithm from a particular bank, such as the subscriber 105illustrated in FIG. 3E. Next, the payload B is recognized by thelistener 330C, which transmits the payload B, or in some embodimentsgenerates a new payload that includes additional information indicatedby the subscriber 105, to the subscriber 105. As noted above, thisprocess advantageously is performed in real-time or near real-time inresponse to receiving of the original balance change event by thenotification module 154.

In some embodiments, the payloads are in an “atomic format” thatprovides minimal information regarding the event and any calculatedcustom data (e.g., calculated scores). For example, as shown in FIG. 3E,the custom payload B that is transmitted to the subscriber 105 includesonly two data elements, a consumer identifier and a calculated bank riskscore associated with that consumer identifier. Provision of only thisminimal level of information allows the system to process larger amountsof events and more quickly and efficiently transmit payloads tosubscribers, which can help provide distribution to a wider range oflisteners and/or subscribers. The small payloads may be used by thesubscribers to then provide alerts and notifications to consumercomputing devices 130 that are also small in payload size to furtherimprove speed and efficiency of the dissemination of information back tothe individual, thus supporting the implementation of a response insubstantially real-time. Thus, the payload may not need to send a fullcredit file, or a substantial portion thereof, but may only need totransmit the information the subscriber is interested in. Then, if thesubscriber is further interested, the subscriber may request for morecredit data or a full credit file for the individual.

FIGS. 3F and 3G are example payloads that may be provided to asubscriber. The payload in FIG. 3F illustrates a version number for thepayload, a sourceID that may be used as an identifier for thetransmitter of the payload, a UniqueTransactionID used to identify theindividual, and an event type of 2. The event may trigger a listenerbased on the EventType matching an event type to which a subscriber hassubscribed. For example, event type 2 may refer to a change in address.Thus, the payload includes information on the address of the individual.Furthermore, the payload may include a CompanyID that may indicate thesource of the change of address for the individual (e.g. the individualrequests a change of address in a company associated with the identifierNationalB). FIG. 3G is another example of a payload, where a consumeridentifier is sent, and the event type is a 4. In this example, thisevent type references a change in credit score. Thus, the payload alsotransmits the score of 733, and a change in the score of +25 points.FIG. 3H is another example of a payload including aCreditBureauSubscriberID that may be used to identify the individualassociated with the credit data using a credit bureau identifier of theindividual. In this example, the EventType is “I”, which indicates acredit inquiry. Thus, subscribers enrolled to receive alerts on creditinquiries may receive a payload include data similar to what isillustrated in example 3H. Information identifying the entity thatsubmitted the inquiry request may be included as well, such as the nameand address.

As a further example of event and alert content (e.g., the payload ofthese communications), below are some example payloads. These examplesdo not limit the type or content of data included in payloads in otherembodiments. First below is an example of an alert payload, such as thedata that may be received from a credit bureau by the notificationsystem indicating that an inquiry request was received for theindividual, John Doe:

-   -   {“Id”:“XYZ23424242342323”,    -   “CompanyId”:“3323”,    -   “PortfolioId”:“11”,    -   “CampaignId”:“42111”,    -   “VersionNum”:“001”},    -   “EventInfo”:{“EventType”:“X”,    -   “ExperianConsumerIdentifier”:“V”,    -   “EventDisplayCode”:“SECUR”,    -   “MonitoredAccount”:“PIN00432425243242”,    -   “ConsumerStatementlndicator”:“A”,    -   “FactaCode”:“26”,    -   “FCRAAttr”:“00 0100”},    -   “CustomerSuppliedName”:{“Name”:{“FirstName”:“JOHN”,“MiddleName”:“D”,    -   “Surname”:“DOE”,    -   “SecondSurname”:“DOETWO”,“Gen”:“D”}},    -   “CustomerSuppliedData”:“CUSTOMER SUPPLIED DATA PRESENT”,    -   “BestAddressInformation”:{“PrimaryStreetId”:“1111”,    -   “PreDirectional”: null,    -   “StreetName”:“STREET”,    -   “PostDirectional”:null,    -   “StreetSuffix”:“ST”,    -   “UnitType”:null,    -   “UnitID”:null,    -   “City”:“DOETOWN”,    -   “State”:“MN”,    -   “Zip”:“111111”,    -   “NonStandardAddress”:null},    -   “SecurityAlertEventInformation”:{“SecurityAlertDate”:“234234234”,    -   “SecurityAlertType”:“26”,    -   “SecurityAlertText”:“26& 2016-11-22 3999997 ID SECURITY ALERT:        FRAUDULENT APPLICATIONS MAY BE SUBMITTED IN MY NAME OR MY        IDENTITY MAY HAVE BEEN USED WITHOUT MY CONSENT TO FRAUDULENTLY        OBTAIN GOODS OR SERVICES. DO NOT EXTEND CREDIT WITHOUT FIRST        VERIFYING THE IDENTITY OF THE APPLICANT. THIS SECURITY ALERT        WILL BE MAINTAINED FOR 90 DAYS BEGINNING 07-10-15.”}.    -   “NumOfStatements”:“0001”,    -   “ConsumerStatement”:[{“StatementIndicator”:“A”,    -   “StatementType”:“26”,    -   “SubscriberName”:null,    -   “AccountReferenceNumber”:null,    -   “DateOpenedFiled”: null,    -   “AcctCond”:null,    -   “Status”:null,    -   “StatementText”:“26& 2016-11-22 3999997 ID SECURITY ALERT:        FRAUDULENT APPLICATIONS MAY BE SUBMITTED IN MY NAME OR MY        IDENTITY MAY HAVE BEEN USED WITHOUT MY CONSENT TO FRAUDULENTLY        OBTAIN GOODS OR SERVICES. DO NOT EXTEND CREDIT WITHOUT FIRST        VERIFYING THE IDENTITY OF THE APPLICANT. THIS SECURITY ALERT        WILL BE MAINTAINED FOR 90 DAYS BEGINNING 07-10-15.”}]}

Next, below is an example of a custom data package that may be generatedby the notification system and transmitted to subscribers to inquiryrequests (for a group of individuals that includes John Doe), such as inan HTTP data package or via an API.

-   -   {“Id”:“RTE000022421000110000008357T60023001”,    -   “CompanyId”:“224210”,    -   “PortfolioId”:“11”,    -   “CampaignId”:“8357”,    -   “VersionNum”:“001”},    -   “EventInfo”:{“EventType”:“I”,    -   “ExperianConsumerIdentifier”:“KLJFOI34343DSFAD”,    -   “EventDisplayCode”:“INSTI”,    -   “MonitoredAccount”:“POSITIVE9227”,    -   “ConsumerStatementIndicator:null,    -   “FCRAAttr”:“00 0601”},    -   “CustomerSuppliedName”:{“Name”:{“FirstName”:“JOHN”,    -   “MiddleName”:“D”,    -   “Surname”:“DOE”,    -   “SecondSurname”:null,    -   “Gen”: null}},    -   “CustomerSuppliedData”: null,    -   “BestAddressInformation”:{“PrimaryStreetId”:“1111”,    -   “PreDirectional”: null,    -   “StreetName”:“STREET”,    -   “PostDirectional”:null,    -   “UnitType”:null,    -   “UnitID”:null,    -   “City”:“DOETOWN”,    -   “State”:MN”,    -   “Zip”:“111111”,    -   “NonStandardAddress”:null},    -   “InquiryEventInformation”:{“KOB”:“IZ”,    -   “PurposeType”:“OA”,    -   “InquiryDate”:“2016-11-22”}}

Below is an example custom payload that may be transmitted to asubscriber, such as a credit access control system associated with acredit bureau, to request freezing of an individual's credit file:

-   -   {“RTTRG”:{“RecordType”:“T”,“VersionNum”:“2.00”,    -   “UniqueTransactionId”:“65465464536546543”,    -   “EventType”:“2”,    -   “SystemID”:“CAP”,    -   “ReturnedPin”:“ ”,    -   “LoggingPin”:251369794,    -   “OptOut”:“ ”,    -   “OnsInd”:“ ”,    -   “FCRAAttr”:“ ”,    -   “InquiryPre”:“ ”,    -   “CrsReferralPre”:“ ”},    -   “RTFRZ”:{    -   “NCACId”:“5445343”,    -   “Type”:“FREEZE”,    -   “CapId”:“4534543543543”,    -   “StartDate”:“2016-11-22”,    -   “AdditionalText”:“A security freeze has been successfully placed        on your credit report.”}}

Below is an example event payload that may be received by thenotification system, indicating that the security freeze has been placedon the individuals credit file:

-   -   {“Id”:“RTE00002242100011000000835707222016001753000003655”,    -   “TransactionInfo”:{“EventDeliveryDate”:“2016-11-22”,    -   “EventDeliveryTime”:“001753”,    -   “CompanyId”:“45454”,    -   “PortfolioId”:“11”,    -   “CampaignId”:“8357”,    -   “VersionNum”:“001”},    -   “EventInfo”:{“EventType”:“2”,    -   “ExperianConsumerIdentifier”:“235445243DFGSDFG3456345”,    -   “EventDisplayCode”:“FRTHL”,    -   “MonitoredAccount”:“PIN45345243”,    -   “ConsumerStatementIndicator:null},    -   “CustomerSuppliedName”:{“Name”:{“FirstName”:“JANE”,    -   “MiddleName”:null,    -   “Surname”:“DOE”,    -   “SecondSurname”:null,    -   “Gen”: null}},    -   “CustomerSuppliedData”: null,    -   “FreezeEventInformation”:{“NCACId”:“454545454545”,    -   “Type”:“FREEZE”,    -   “CapId”:“45454545454”,    -   “StartDate”:“2016-11-22”,    -   “AdditionalText”:“A security freeze has been successfully placed        on your credit report.” }}

FIG. 4A is an illustrative representation of a table 400 associatingcredit data with other information, such as information from the inquiryfor credit data, along with corresponding personal information for theindividual. The data represented in illustrative table 400 may be storedin one or more data stores accessible to the notification system 150.The data may be determined and stored, for example, based on informationprovided by each financial institution to the notification system 150,either in bulk prior to sending individual requests for credit data orin a piecemeal fashion as requests for credit data or other requests areprocessed by the notification system 150. In some embodiments, when thenotification system 150 receives indications of requests for creditdata, the notification system 150 may consult the data in table 400 todetermine information on the consumer and the request for credit data tobe used in generating an event to broadcast to the other entities.

Example table 400 includes columns indicating the name of an individual420, consumer personal identification information 422, other consumerinformation 424 that may be relevant to the alert, credit information426 of the individual, and credit request history 428 for the individualor related information. This information can be gathered from one ormore of the credit data store 121, the non-credit consumer informationdata store 112, and/or other database. The table of information may bestored in separate tables of information located within differententities, but accessible by the notification system 150.

As illustrated in table 400, row 402 includes information associatedwith Jordan Lee, 404 for John Doe, and 406 Jim Smith. Column 422includes consumer PID for the three individuals, which may be relevantfor the notification system to send to the subscriber when thesubscriber is generating the alert to send to the individual, or eventobject to generate by the notification system with respect to theindividual's action(s). For example, the consumer PID may include thecontact information to send the alert, such as a phone number or emailaddress.

Column 424 may include consumer information and column 426 credit dataregarding the three individuals. For example, for Jordan Lee, there maybe information about his income that may be relevant to an alert to sendbased on the request for credit data. For example, if it is known thatJordan Lee's income is $422,000 and his credit score is above a certainthreshold, then the notification system 150 can use this information todetermine an appropriate event for the request for credit data (e.g. anevent for lenders that may have certain loans at better rates forindividuals with high income and good credit score than the loansprovided by the lender associated with the requesting entity).

In another example, John Doe in row 404 has been watching a lot ofonline videos and a large portion of his browser history is direct toboat purchases and price comparisons around $70,000 in column 424, andthe credit request history includes a requested loan for $70,000, whichmay indicate his decision to purchase a boat, which may be used by thenotification system 150 to generate an event object. In row 406, JimSmith recently purchased a stroller as shown in column 424, openedseveral credit cards in a short period of time and has many purchasesdirected to childcare. The notification system 150 may generate an eventobject based on these types of information (e.g. identifies entities orsubscribers to broadcast event information that may have products orservices related to products or services that the user is currentlyseeking). A subscriber may receive an event message regarding John Doeand suggest better loan rates based on a discount for loans for boatpurchases. A credit card supplier may offer a credit card with a highbalance and low interest rate to suggest Jim Smith to consolidate histotal debt of $13,455 into a single credit card.

FIG. 4B is an illustrative representation of a table associatingfinancial institutions with vendors and/or service providers, along withcorresponding contact and other information. Column 470 shows theidentifier for the vendor/service provider, shown in column 472. Column474 shows contact information for the vendor/service provider. Thevendor/service provider is linked with a financial institution 476.

The requesting entity can be associated with the request by matchingdata included in the request with data previously stored in table 450.In this manner, the notification system may quickly provide an alert tosubscribers who may use the alert to send information to the consumerthat includes additional information (such as the identity of therequesting entity) that was not necessarily included in the request forcredit data itself. As illustrated in table 450, row 452 includes afinancial entity identifier (“ABL5533”) associated with the vendor “ABLCable Co.” In some embodiments, the identifier may be included in therequest for credit data without any other indication of the identity ofthe product/service provider. The product/service provider is tied tothe financial institution American Bank. The vendors for American Bankare identified as “ABL Cable Co.” and “Quality Cellular Phones” incolumns 452 and 454. The identifier may also be an identifier for afinancial institution, which may have been the identifier included inthe request for credit data. For example, the request for credit datamay have been associated with an individual visiting BL Cable Co.(vendor of row 452), but the request for credit data may include theidentifier 545AM1 associated with American Bank. In some embodiments,the requests for credit data from the vendor/service providers mayinclude the vendor identifier associated with the requesting entity,such that the notification system can determine the name and contactinformation of the requesting entity by matching the vendor identifierin the request with data in table 450. As indicated in rows 452, 454,456, the stored data associated with each vendor or service providerincludes contact information, which may include multiple forms ofcontact information for a single vendor, such as one or more e-mailaddresses and/or phone numbers. The stored information may also includecontact information for the financial institution.

FIG. 5 is a block diagram of an example notification system incommunication with various publishers and subscribers. The notificationsystem includes a message QUEUE client that queues the messages as theycome into the notification system, sends the messages to thenotification module (or other middleware, data streaming, or otherpublish and subscribe technology), the notification module contains thecatalog of events that the subscriber can enroll in, the servicesorchestration uses the USB to recognize events and publish events tosubscribers to the event, and the subscriber or informal listener canreceive such events.

The notification system may receive data to and/or send data to avariety of modules that may be internal, external, or a combination ofboth to the notification system. For the sake of discussion, thedescriptions will be shown to be external to the notification system.

In some embodiments, the ecosystem includes Sending Contributing Datawhich are applications responsible for sending data from contributorsinto Credit Bureau that may affect credit data. The Sending ContributingData can be both Subscriber and Publisher of Credit events actions to besent through notification system.

In some embodiments, the ecosystem includes Consumer Disputes that is anapplication responsible for creation and management of consumer disputes(e.g. disputes reported to consumer call center either through Agents orthrough Webapps or API). The Consumer Disputes can be both subscriberand publisher of credit events actions to be sent through notificationsystem.

In some embodiments, the ecosystem includes Data Furnishers (real timeupdates) that can be responsible for providing data to the bureau eitherthrough Real time, API, or Batch process.

In some embodiments, the ecosystem includes Freeze/block transactionsthat are transactions where specific data furnishes account informationand status could be disputed. In some embodiments, the freeze/blocktransactions cannot be accessed. This transaction types may be publisherof events to the notification system that others can subscribe to.

In some embodiments, the ecosystem includes a Billing System that may beresponsible for processing billing transactions from the system ofrecords and feeding the records to a central billing system, which couldbe both a publisher or subscriber to the notification system.

In some embodiments, the ecosystem includes a Customer Master that maybe responsible for maintaining customer information (e.g. maintainingcredit files for individuals) and the products for which the individualsare authorized to use.

In some embodiments, the ecosystem includes Business InformationServices that may be responsible for managing Business informationrelated to credit data similar to a consumer information related tocredit data. The Business Information Services can use the sameunderpinning notification infrastructure to perform subscription andpublication of events.

In some embodiments, the ecosystem includes Decision Analytics that maybe responsible for managing decisioning related products such modeling,aggregation, tools and fraud services. The ecosystem may also include anEvent Transaction Analytics that is done at an event level (e.g. atomicpayload level). The Event Transaction Analytics may also feed into theDecision Analytics for further processing and analysis at the macrolevel.

In some embodiments, the ecosystem includes a real time prescreennotification that may be responsible for receiving event notificationthat is related to a prescreen of customers. For example, events may bepublished to subscribers that would like to prescreen customers based ona certain credit criteria. The notification system may send eventnotifications to marketing services that may use the published eventnotifications to market to consumers. The notification system may sendevent notifications to external clients that may have interest in thepublished event notifications.

In some embodiments, the ecosystem includes the real-time eventnotification that can receive notification in real-time, orsubstantially real time. The real-time event notification may then beable to notify or alert the individual in real-time and empower theindividual with information at the point of sale or during negotiation.In some embodiments, the ecosystem includes a real-time account reviewnotification, where a business uses an existing relationship with theindividual. For example, if an entity is notified of a new delinquencyreported on one of their subscribers, the entity may take proactiveaction to mitigate risks while managing their accounts.

In some embodiments, the notification system may send events to acontinuous scoring module that continuously listens to a particularscore, such as changes to a credit score.

In some embodiments, the notification system may send eventnotifications through HTTP direct pushes, in continuous batches, throughAPI services, and other modes of communication. In some embodiments, theecosystem includes an event transaction enrichment which may beresponsible for the ability to add enhancement in real time to an event.For example, upon closing a balance on a revolving account, the eventcan be enriched by further calculating a generic credit score or acustom model score. The event enhancement can be sent with or withoutthe event in combination.

In some embodiments, the ecosystem includes a skip tracing notification,which notifies any changes to credit data from a collectionsperspective. For example, a new address for the consumer will be sent tothe skip tracing notification.

In some embodiments, the ecosystem includes platforms that can deliverproducts such as prescreen or account monitoring. The ecosystem may alsoinclude products for commercial application, in a business-to-businesscontext or directly to consumers. Furthermore, the ecosystem may alsoinclude platforms that allow consumers to share their own credit reportsor other credit data to others, such as sharing credit reports withpotential tenant screeners for renting.

In general, the word “module,” as used herein, refers to logic embodiedin hardware or firmware, or to a collection of software instructions,possibly having entry and exit points, written in a programminglanguage, such as, for example, Java, Lua, C or C++. A software modulemay be compiled and linked into an executable program, installed in adynamic link library, or may be written in an interpreted programminglanguage such as, for example, BASIC, Perl, or Python. It will beappreciated that software modules may be callable from other modules orfrom themselves, and/or may be invoked in response to detected events orinterrupts. Software modules configured for execution on computingdevices may be provided on a computer readable medium, such as a compactdisc, digital video disc, flash drive, or any other tangible medium.Such software code may be stored, partially or fully, on a memory deviceof the executing computing device, such as the computing system 700, forexecution by the computing device. Software instructions may be embeddedin firmware, such as an EPROM. It will be further appreciated thathardware modules may be comprised of connected logic units, such asgates and flip-flops, and/or may be comprised of programmable units,such as programmable gate arrays or processors. The modules describedherein are preferably implemented as software modules, but may berepresented in hardware or firmware. Generally, the modules describedherein refer to logical modules that may be combined with other modulesor divided into sub-modules despite their physical organization orstorage.

Conditional language, such as, among others, “can,” “could,” “might,” or“may,” unless specifically stated otherwise, or otherwise understoodwithin the context as used, is generally intended to convey that certainembodiments include, while other embodiments do not include, certainfeatures, elements and/or steps. Thus, such conditional language is notgenerally intended to imply that features, elements and/or steps are inany way required for one or more embodiments or that one or moreembodiments necessarily include logic for deciding, with or without userinput or prompting, whether these features, elements and/or steps areincluded or are to be performed in any particular embodiment.

Any process descriptions, elements, or blocks in the flow diagramsdescribed herein and/or depicted in the attached figures should beunderstood as potentially representing modules, segments, or portions ofcode which include one or more executable instructions for implementingspecific logical functions or steps in the process. Alternateimplementations are included within the scope of the embodimentsdescribed herein in which elements or functions may be deleted, executedout of order from that shown or discussed, including substantiallyconcurrently or in reverse order, depending on the functionalityinvolved, as would be understood by those skilled in the art.

All of the methods and processes described above may be embodied in, andpartially or fully automated via, software code modules executed by oneor more general purpose computers. The methods may be executed on thecomputing devices in response to execution of software instructions orother executable code read from a tangible, non-transitory computerreadable medium. A tangible computer readable medium is a data storagedevice that can store data that is readable by a computer system.Examples of computer readable mediums include read-only memory,random-access memory, other volatile or non-volatile memory devices,CD-ROMs, magnetic tape, flash drives, and optical data storage devices.

Although this disclosure has been described in terms of certain exampleembodiments and applications, other embodiments and applications thatare apparent to those of ordinary skill in the art, includingembodiments and applications that do not provide all of the benefitsdescribed herein, are also within the scope of this disclosure.

Unless otherwise explicitly stated, articles such as “a” or “an” shouldgenerally be interpreted to include one or more described items.Accordingly, phrases such as “a device configured to” are intended toinclude one or more recited devices. Such one or more recited devicescan also be collectively configured to carry out the stated recitations.For example, “a processor configured to carry out recitations A, B andC” can include a first processor configured to carry out recitation Aworking in conjunction with a second processor configured to carry outrecitations B and C.

Disjunctive language such as the phrase “at least one of X, Y, or Z,”unless specifically stated otherwise, is otherwise understood with thecontext as used in general to present that an item, term, etc., may beeither X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z).Thus, such disjunctive language is not generally intended to, and shouldnot, imply that certain embodiments require at least one of X, at leastone of Y, or at least one of Z to each be present.

What is claimed is:
 1. A computing system comprising: an electronic datastore configured to store credit data; a first computing systemcomprising one or more computing devices, said computing system incommunication with the electronic data store and configured to at least:receive an indication of at least one of: a request for informationregarding an individual submitted by a requesting entity or informationabout an action that affects the individual's credit data; based atleast in part on the indication, determine that the request forinformation meets one or more event broadcast criteria; generate abroadcast event object, wherein the broadcast event object includes anevent type and at least a portion of the indication of the request forinformation; electronically post the generated broadcast event object toan enterprise service bus, wherein posting the generated broadcast eventobject triggers a plurality of listeners based on the event type,wherein the event type comprises at least one of: requesting for a loan,paying off a debt, or a credit inquiry, each of the plurality oflisteners having access to the enterprise service bus and eachassociated with processing and/or reporting related to particularbroadcast event objects to identify a plurality of subscribersregistered to receive broadcast event objects from the enterpriseservice bus that relate to the event type, wherein the plurality ofsubscribers are computing systems associated with one or more entitiesother than the individual, the requesting entity, and the plurality oflisteners; and send the broadcast event object to the identifiedsubscribers, wherein at least one identified subscriber is configured togenerate a message based on the broadcast event object and transmit themessage directly to the individual.
 2. The computing system of claim 1,wherein the identified subscribers receive the broadcast event object atsubstantially the same time as each other.
 3. The system of claim 1,wherein the message is further based at least in part on informationabout the individual not included in the request for information.
 4. Thecomputing system of claim 1, wherein the request comprises at least oneof: a request for a credit file, a credit status dispute, a creditfreeze, a credit lock, a credit thaw, a credit lift, or a securityevent.
 5. A computer-implemented notification method comprising:receiving an indication of at least one of: a request for informationregarding an individual has been submitted by a requesting entity orinformation about an action that affect credit data of the individual;based at least in part on the indication, determine that the request forinformation meets one or more event broadcast criteria; generate abroadcast event object associated with the indication, wherein thebroadcast event object includes at least (a) data associated with therequest for information regarding the individual, and (b) an indicatorof an event type; electronically post the broadcast event object to anenterprise service bus, wherein posting the broadcast event objecttriggers a plurality of listeners based on the event type, wherein theevent type comprises at least one of: requesting for a loan, paying offa debt, or a credit inquiry; identify subscribers registered to receivebroadcast event objects from the enterprise service bus that relate tothe event type; and send the broadcast event object to the identifiedsubscribers, wherein receipt of the broadcast event object by at leastone identified subscriber causes the at least one identified subscriberto generate a message based on the broadcast event object and send themessage directly to the individual.
 6. The method of claim 5, whereinthe message includes suggestions of actions the individual can performto improve the information requested by the requesting entity.
 7. Themethod of claim 5, wherein the request comprises at least one of: arequest for a credit file, a credit status dispute, a credit freeze, acredit lock, a credit thaw, a credit lift, or a security event.
 8. Themethod of claim 5, wherein the indication is associated with a change incredit data, and the event broadcast criteria comprises whether thechange in credit data meets a threshold value.
 9. A computer-implementednotification method comprising: receiving an indication of an actionthat affects credit information related to an entity; generate a firstbroadcast event object associated with the credit information, whereinthe first broadcast event object includes at least data associated withthe update; electronically post the generated first broadcast eventobject to an enterprise service bus, wherein posting the generated firstbroadcast event object triggers a plurality of listeners based on anevent type, each of the plurality of listeners having access to theenterprise service bus and each associated with one or more of:processing or reporting related to particular broadcast event objects toidentify a plurality of subscribers registered to receive broadcastevent objects that relate to the event type associated with theindication, wherein the event type comprises at least one of: a requestfor a loan, paying off a debt, or a credit inquiry, wherein theplurality of subscribers include a first subscriber that comprises afirst computing system associated with a second entity that is differentthan the entity and the listeners; and send the first broadcast eventobject to a first computing system of the first subscriber, wherein thebroadcast event object causes the first computing system of the firstsubscriber to generate a message based on the broadcast event object andsend the message directly to the individual.
 10. The method of claim 9,wherein the request comprises at least one of: a request for creditinformation, a request for a credit file, a credit status dispute, acredit freeze, a credit lock, a credit thaw, a credit lift, or asecurity event.
 11. The method of claim 9, further comprising: receivingnon-credit information related to the entity, wherein the broadcastevent is further associated with the non-credit information of theentity.
 12. The method of claim 9, further comprising: determine thatthe update to credit information meets one or more event broadcastcriteria, wherein broadcasting the first broadcast event object is inresponse to determining that the update to the credit information meetsthe one or more event broadcast criteria.
 13. The method of claim 12,wherein the update comprises a change in a credit score, and thebroadcast criteria comprises whether the change in the credit scoremeets a threshold value.
 14. The method of claim 12, wherein the messageincludes suggestions the entity can perform to improve the creditinformation.
 15. The method of claim 12, further comprising: generatinga second broadcast event object based on the first broadcast eventobject; and broadcast the second broadcast event object to a subscriber.16. The system of claim 1, wherein a listener of the plurality oflisteners is configured to, in response to being executed by the firstcomputing system, generate a first payload for a first subscriber and asecond payload for a second subscriber, wherein the first payload isdifferent than the second payload.
 17. The system of claim 1, wherein isthe first computing system is further configured to, in response to theplurality of listeners being executed by the first computing system,generate a first payload including first data, and generate a secondpayload for a second listener of the plurality of listeners based on thefirst data, wherein the second listener is configured to generate athird payload including second data and send the third payload to atleast one of the plurality of subscribers.
 18. The system of claim 1,wherein sending the broadcast event object to the identified subscribersoccurs in real time with respect to receiving the indication.
 19. Thesystem of claim 1, wherein transmitting the message directly to theindividual occurs in real time of the at least one identified subscriberreceiving the broadcast event object.